The present invention relates to interprocess communications (IPC), for transferring data or resource control between processes running in a data processing system or device.
There are many instances where interprocess communication (IPC) is required within a data processing system. During the operation of a resource manager computer program such as the MQSeries messaging communication manager from IBM Corporation, IPC is required for transferring data and control from one process to another, while implementing process isolation which separates a process"" resources from other processes. The two processes communicating via an IPC mechanism may be, for example, an application program and a process within a resource manager program. (IBM and MQSeries are trademarks of International Business Machines Corporation.)
It is known in the art for an IPC implementation to be re-connectablexe2x80x94i.e. two processes A and B communicate via an IPC link and when one of these processes A has ended its communication with its communication partner process B, another process C must be able to establish a communication with the process B and this must be possible even if the previous communication ended in an uncontrolled manner (e.g. unexpected termination of process A). This ability to re-connect, or reuse the IPC mechanisms, is important since it enables a single locatable name or address to be used for all IPC conversations with a particular process (B in the above example) and avoids having to continually repeat the IPC link creation steps of allocating a shared memory block for the link and allocating any other resources such as semaphores, mutices, etc.
However, the reliance by many re-connectable IPC mechanisms on obtaining mutex locks for every data transfer via the link (to prevent resources being left in an inconsistent and unresolvable state when failures occur) entails a processing overhead which can significantly reduce processing efficiency during normal forward processing. Since most processing does not result in failures, the processing overhead of the known mechanisms for dealing with failures is undesirable and a more efficient yet still re-connectable IPC mechanism is desirable. The alternative is a non-recoverable approach which optimizes processing for the non-failure case and does not enable reuse of the same named link. This is generally unacceptable since it would allow certain failures to have a major impact on processing efficiency.
One known IPC implementation is of a flip/flop design, in which control is handed from process A to process B, process B then passes control back to process A when it has completed its task, and this then repeats. For optimal efficiency this passing of control is implemented by using a pair of semaphores, one owned by each end of the link. To pass control (which we will refer to hereafter as the baton for ease of reference) a process resets its own semaphore then posts (i.e. instructs updating of) the other process"" semaphore. On being posted the second process picks up the baton and takes control, and this passing of the baton is symmetrical. The data passed between processes is held in shared memory which both processes can read and write to.
This implementation is IPC in its simplest form, but a problem with this approach is that there is a small time window between resetting one semaphore and posting the other where, effectively, neither process holds the baton. If one of the processes was to fail during this window, a new process wishing to start a conversation with the remaining process would not be able to. The problem is that neither process can take the baton in case the other process is using it, to avoid resource update inconsistencies, and since in this situation neither process has the baton we have a stalemate situation.
In a first aspect, the present invention provides a method for recovery from interprocess communication failures, the method comprising: in response to an initiator process requesting interprocess communication (IPC) with a responder process via an IPC link, determining whether the initiator process has write control of the IPC link and setting an indicator if the initiator process does not have said control; a process other than said initiator process checking said indicator and, in response to determining that said indicator has been set, notifying the initiator process to take said control.
The step of setting the indicator may comprise setting a token or otherwise indicating that the initiator process does not have control, so that a separate process can recognize this lack control and take appropriate action. The step of checking whether the indicator has been set is preferably implemented in response to non-establishment of interprocess communications within a preset time period;. The checking step and the step of notifying the initiator process to take control are preferably implemented by the responder process, but alternatively could be implemented by a separate process which manages the link.
The present invention addresses the problem of neither of the initiator and responder processes being able to take control of the IPC link in some circumstances, in case the other process already has control. This arises because of the requirement for atomic resource updates (i.e. updates must not leave resources in an inconsistent state) and can result in a stalemate situation. Known solutions to this problem which use mutex locking for every transfer of write control of the link during normal forward processing are too inefficient in systems which have a high communication throughput.
Using the present invention, a failure to establish communications via an IPC link, which resulted from processes having terminated when neither process has control, can be resolved by the initiator process recognizing situations in which it does not have write control of the IPC link and causing the responder process (or a separate process which manages the link) to also recognize when such situations have arisen. This avoids a potential stalemate situation without compromising the requirement for atomic updates and without reliance on mutex locking of IPC control mechanisms for every transfer of data or control.
In a preferred embodiment of the invention, a method for recovery from interprocess communication failures comprises: creating an interprocess communication (IPC) link for communications between an initiator process and a responder process, including providing a pair of tokens which are each associated with one end of said IPC link; responsive to an initiator process requesting communications via said IPC link, determining whether the initiator process has write control of the IPC link and, if not, incrementing the token associated with the initiator process"" end of the link; if said request for communications is unsuccessful (for example, if communications are not established within a set time period), comparing the incremented token with the token associated with the responder process"" end of the link to determine whether said tokens are synchronized; if said tokens are not synchronized, notifying the initiator process to take said control and resynchronizing said tokens.
In preferred embodiments of the invention, subsequent to comparing the tokens, the responder process relinquishes control of the link and notifies the initiator process (e.g. by posting a semaphore associated with the initiator), and then subsequently resynchronizes the tokens. The initiator process responds to the notification by taking control of the link. The reason for resynchronizing the tokens subsequent to notifying the initiator process is to avoid a problem that could otherwise occur if an initiator process identifies resynchronized tokens and starts communicating with the responder before it receives a notification from the responder, since the responder""s notification to the initiator could then be mistaken for a reply to the new communication and the initiator may try to process a reply it does not have).
The setting, checking and resetting of tokens has minimal impact on processing efficiency, particularly since these steps are only implemented in the unusual situation of a requesting initiator process not having control, and so the potential stalemate situation has been avoided with far less overhead than the alternative of using mutex locks for every transfer of data or control.
In preferred embodiments of the invention, the initiator process merely increments its token to flag the discrepancy that it does not have control and then waits for either the responder or a link manager process associated with the responder to notice a discrepancy between the initiator and responder processes"" tokens. This discrepancy is preferably noticed when a token comparison is performed in response to the responder or link manager process determining that a time period has expired without establishment of communications. The initiator process does not proactively attempt to obtain write control of the IPC link because such an attempt could conflict with operations performed by the responder and leave resources in an inconsistent state.
According to a preferred embodiment of the invention, one of a pair of flags is associated with each end of the IPC link for indicating which end of the link (i.e. which of the initiator and responder processes) has write control of the link, and the determination of whether the initiator process has control of the IPC link is performed by checking the respective flag at the initiator process"" end of the link.
Preferably, the initiator and responder processes have a client/server relationship or a similar defined role in which multiple initiator processes can communicate with a responder process via the IPC link, but only one initiator process is attached to each link at any time and each link is associated with a single responder process. Thus, a new initiator process only attaches to the IPC link after termination of a first initiator process"" communication, and the present invention solves a problem which can arise if the first initiator process terminates abnormally.
The present invention also provides a computer program, preferably recorded on a machine-readable recording medium, comprising program instructions for controlling the operation of a data processing system to perform a method as described above.
The invention also provides a data processing system including components for implementing a method as described above.